As the value and use of information continues to increase, individuals and businesses seek additional ways to process and store information. One option available to users is information handling systems. An information handling system generally processes, compiles, stores, and/or communicates information or data for business, personal, or other purposes thereby allowing users to take advantage of the value of the information. Because technology and information handling needs and requirements vary between different users or applications, information handling systems may also vary regarding what information is handled, how the information is handled, how much information is processed, stored, or communicated, and how quickly and efficiently the information may be processed, stored, or communicated. The variations in information handling systems allow for information handling systems to be general or configured for a specific user or specific use such as financial transaction processing, airline reservations, enterprise data storage, or global communications. In addition, information handling systems may include a variety of hardware and software components that may be configured to process, store, and communicate information and may include one or more computer systems, data storage systems, and networking systems.
Increasingly, information handling systems are deployed in architectures by which information handling systems boot their respective operating systems remotely from storage resources via a network. Often, these architectures are employed for numerous reasons, including without limitation: (1) increased concern with the security of data-at-rest in information handling systems, particularly in portable computing devices (e.g., notebooks, laptops, and handhelds); and (2) simplified operating system management.
In a typical remote boot scenario, a remotely-booted information handling system (which may also be referred to as a “client”) may initially be powered on. After the client powers up, it may issue a broadcast over a network (e.g., via an integrated network interface card) seeking boot instructions. Upon receiving the broadcast, a configuration server (e.g., a dynamic host configuration protocol, or “DHCP,” server) may reply to the client with an address (e.g., an Internet Protocol address) for a boot management server. The client may then communicate with the boot management server to request parameters required for the client to boot. For example, in Internet Small Computer System Interface (iSCSI) protocol implementations, the boot client may request iSCSI parameters needed to communicate to an iSCSI storage resource storing a boot image (e.g., target portal, target iSCSI qualified name, initiator iSCSI qualified name, challenge-handshake authentication protocol credentials, etc.).
The boot management server may respond to the client with the requested parameters, and the client may store such parameters. The client may also use the parameters to communicate with a remote storage resource storing a boot image (e.g., operating system) for the client. Accordingly, the client may remotely boot the image from the remote storage resource.
However, in scenarios in which multiple information handling systems are booted using common resources (e.g., common storage resources and/or common boot management servers) such common resources may not have sufficient capacity to allow the information handling systems to boot within a preferred time. In implementations where the information handling systems include “mission-critical” or priority computing devices, such delayed booting may be particularly undesirable.